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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
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Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Services and Protocols for 
Advanced Networks (SPAN). 
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Scope 



The present document specifies the protocol that is used by the Local Emergency Operator to obtain the location 
information that is registered on the Mobile Operator Location Server. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

[1] EPSG geodesy parameters Version 6.3, February 2002. 

NOTE: http ://ww w .epsg .org/ . 



3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

APSG Americas Petroleum Survey Group 

EMTEL EMergency TELecommunication services 

EPSG European Petroleum Survey Group 

ISO International Standards Organization 

LCS Local Contact Service 

LIE Location Interoperability Forum 

MLP Mobile Location Protocol 

POSC Petrotechnical Open Software Corporation 

QOP Quahty Of Position 



4 MLP Lite 112 

A subset of the Location Interoperability Forum (LIE) Mobile Location Protocol (MLP) Version 3.0.0 (6 June 2002) 
sufficient for mobile operators and emergency number service operators to implement an initial service where the 
emergency number operator can request the location of a phone from the mobile operator and receive either a valid 
response or an error response in reply. 
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Mobile Operator 
Location Server 



Emergency 

Operator 

application 



It is anticipated that after initial implementation, some Mobile Operators will implement the functionality to initiate a 
position fix on the origination of a call to 1 12 by the user and push the resulting location information to the Emergency 
Operator 



Emergency 

Operator 

application 




Mobile Operator 
Location Server 



Please see full LIF specification at http://www.openmobilealliance.org/tech/lif for further details and information. 
Note that in this implementation of the LIF MLP protocol: 

• ALL compulsory LIF elements are compulsory. 

• Some optional LIF elements are compulsory. 



Name and address data 



The LIF MLP standard does not include Name and Address type fields but does include an extension mechanism to 
allow additional elements to be added. 

A Name and Address extension is included in this specification to enable fixed line operators to adopt the same protocol 
as mobile operators to provide location information to emergency services: 

• Potential data sources to populate these fields include: 

installation address for fixed lines phones; 

addresses "reverse geocoded" from latitude, longitude position of mobile handset; 

location of pico cells within buildings. 

Note that the referenced extension (and therefore the structure and elements within this extension) could be different for 
different countries, different operators and different emergency services. 

I.e. if required the name and address fields and field formats could be defined differently to suit different countries, 
different operators or different emergency services. 
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6 Emergency Location Immediate service (LIF defined 

service) 

The emergency location immediate service is used by the Emergency Operator to retrieve the position of a mobile 
subscriber that has initiated an emergency call from the Mobile Operator. 

The response to the service is required immediately. 

The service consists of the following messages: 

• Emergency Location Immediate Request. 

• Emergency Location Immediate Answer. 

The following message flow encapsulates this service: 

Emergency Mobile 

Operator Operator 



LCS Client 



Location Server 



emergency location immediate request 



emergency location immediate answer 



Request and Answer implemented as: 

Emergency Mobile 

Operator Operator 



LCS Client 



Location Server 



HTTP POST (Service Initiation(hdr, body)) 



HTTP Response (Service Result(hdr?, body)) 
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6.1 Emergency Location Immediate request (subset of LIF 
defined request) 



XML Code 


Notes 


<?xml version="1 .0" ?> 




<!DOCTYPEsvc init SYSTEM 
"MLP SVC INIT 300.DTD"> 




<svc init ver="3.0.0"> 


Service initiation for IVILP Version 3.0.0 


<hdrver="3.0.0"> 


Header for MLP Version 3.0.0 


<client> 


Who is requesting this location fix 


<\6>aaaa....a</\d> 


Emergency operator registered user name for login 


<pwd>aaaa. . . a</pwd» 


Emergency operator password for login 


</client> 




</hdr> 




<eme_lir ver="3.0.0"» 


Emergency Location Immediate Request for MLP 
Version 3.0.0 


<msids> 


Identifier of device to be located 


<msid type="MSISDN">ccpppppppppp</msid> 


Identifier is a MSISDN formatted as Country Code + Phone 
Number (GSM/3GPP should conform to TS 123 003) 


</msids> 




</eme lir 




</svc init> 





6.2 Emergency Location Immediate answer - Valid response 
(subset of LIF defined response) 



XML Code 


Notes 


<?xml version="1 .0" ?> 




<!DOCTYPEsvc init SYSTEM 
"MLP SVC RESULT 300.DTD" [ 




<!ENTITY % extension SYSTEM 


Utilize the LIF extension mechanism to point to the 
DTD defining the National Regulatory Organization 


'http://www.oftel.gov.uk/UK999_MLP_address_extension.dtd'> 
(note this is an example of a dtd) 


Name and Address extension 


%extension; 




]> 




<svc result ver="3.0.0"> 


Service result for MLP Version 3.0.0 


<eme_lia ver="3.0.0"> 


Emergency Location Immediate Answer for MLP 
Version 3.0.0 


<Caller_Location> 


Name and address data elements as defined by 
the referenced DTD above 


<CustomerName>aaaaa...a</CustomerName> 


Registered Customer Name 


<Line1>aaaaa.a</Line 1> 


Address of current location 


<Line2>aaaaa.a</Line 2> 


Notes - 


<Line3>aaaaa.a</Line 3> 


All elements could be defined as optional 


etc 


Elements could be defined differently 


eto 


This is only an example of how to include 
additional fields 


<Line6>aaaaa.a</Line n> 




<PostCode>aaaaa a</PostCode> 


Post Code 


</Caller Location> 




<eme pos> 


Position answer 


<msid type="MSISDN">cccpppppppppp</msid> 


Position is for this MSISDN (formatted as Country 
Code + Phone Number) (GSM/3GPP should 
conform to TS 1 23 003) 


<pd> 


Position description 


<time ui\c_o^i="±hhmm">yyyymmddhhmmss</\.\me> 


Local Date and Time of phone when position was 
measured. 
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XML Code 


Notes 


<shape> 


Shape of uncertainty area 


<EllipticalArea> 


It is an ellipse! 

North 1 angle 

^^SX semiMajor 
^^"^^ Axis 


/ / ^^semiMinor 
/ / ^ Axis 

Note that circle can be described by making semilVlajor 
axis = semlMinor axis 

Default WGS84 Coordinate Reference System is defined 
by LIF to be 4326 by the EPSG authority, (see clause 12) 


<coord> 


Coordinate of the centre of the ellipse 


<X>addd.ddcl</X> 


Latitude in decimal degrees prefixed with N or S 


<Y>addd.ddd</Y> 


Longitude in decimal degrees prefixed with E or W 


</coord> 




<angle>nnn.nn</angle> 


Angle in degrees of rotation of the ellipse measured 
clockwise from north 


<semiMajor>nnnnn</semiMajor> 


Length of semiMajor axis in metres 


<semiMinor>nnnnn</semiMinor> 


Length of semiMinor axis in metres 


<angularUnit>aaaaaa</angularUnit> 


Unit for <angle> (Required LIF parameter but default unit 
is degrees!) 


<distanceUnit>nnnnn</distanceUnit> 


Optional - default unit is meter 


</ EllipticalArea > 




</shape> 




<alt>iir)nn</alt> 


Optional - Altitude of phone if available (in respect to 
coordinate ellipsoid NOT actual height) 


<speed>nnnn</speed> 


Optional - speed in meters/sec if available 


<direction>nnnn</direction> 


Optional - Direction phone is moving if available 


<lev_conf>nnn</lev_conf> 


LIF optional but required by 1 12service - Indicates the 
probability as a percentage that the phone is located 
within the position area defined 


</pd> 




</eme pos> 




</eme lia> 




</svc result> 





£75/ 



10 



ETSI TS 102 164 VI .1.1 (2003-04) 



7 Emergency Location Reporting service (LIF defined 

service) 

The emergency location reporting service is used by the Mobile Operator to push the position of a mobile subscriber 
that has initiated an emergency call to the Emergency Operator. (NB without a request from the Emergency Operator) 

NOTE: Report triggered by the user either originating or releasing a call to 112. 
The service consists of the following messages: 

• Emergency Location Report. 
The following message flow encapsulates this service: 



Emergency 
Operator 



Mobile 
Operator 

LCS Client 



Location Server 



emergency location report 



Request and Answer implemented as: 



Emergency 
Operator 



Mobile 
Operator 

LCS Client 



Location Server 



HTTP POST (Service Result(hdr, body)) 



HTTP Response (Status_Code) 
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7.1 Emergency Location report (subset of LIF defined request) 



XML Code 


Notes 


<?xml version="1.0" ?> 




<!DOCTYPEsvc init SYSTEM "MLP SVC RESULT 300.DTD" [ 




<!ENTITY % extension SYSTEM 


Utilize the LIF extension mechanism to point 
to the DTD defining the National Regulatory 
Organization 


'http://www.oftel.gov.uk/UK999 MLP address extension.dtd'> 


Name and Address extension 


%extension; (note this is an example of a dtd) 




1> 




<svc result ver="3.0.0"> 


Service result for MLP Version 3.0.0 


<emerep ver="3.0.0"> 


Emergency Location Report for MLP Version 
3.0.0 


<eme_event eme_trigger='EME_ORG'> 


What triggered this pushed report - Either 
emergency service user originated the 
emergency call (EME_ORG) or released the 
emergency call (EME REL) 


<Caller_Location> 


Name and address data elements as defined 
by the referenced DTD above 


<CustomerName>aaaaa...a</CustomerName> 


Registered Customer Name 


<Line1>aaaaa.a</Line 1> 


Address of current location 


<Line2>aaaaa.a</Line 2> 


Notes - 


<Line3>aaaaa.a</Line 3> 


All elements could be defined as optional 


etc 


Elements could be defined differently 


eto 


This is only an example of how to include 
additional fields 


<Line6>aaaaa.a</Line n> 




<PostCode>aaaaa a</PostCode> 


Post Code 


</Caller Location> 




<eme pos> 


Position information 


<msid type="MSISDN">cccpppppppppp</msid> 


Position is for this MSISDN (formatted as 
Country Code + Phone Number) (GSM/3GPP 
should conform to TS 123 003) 


<pd> 


Position description 
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XML Code 


Notes 


<time 
u\c_o^W'±hhmm">yyyymmddhhmmss</\\me> 


Local Date and Time of phone when position was 
measured. 


<shape> 


Shape of uncertainty area 


<EllipticalArea> 


It is an ellipse! 

North-" angle 

/ semlMajor 
y^^ ^t\ Axis 


/ /v 

/ / /^semlMinor 
/ / y^ Axis 

Note circle can be described by making semlMajor axis = 
semiMinor axis 

Default WGS84 Coordinate Reference System is defined 
by LIF to be 4326 by the EPSG authority (see clause 12). 


<coord> 


Coordinate of the centre of the ellipse 


<X>addd.ddd</X> 


Latitude in decimal degrees prefixed with N or S 


<y>addd.ddd</y> 


Longitude in decimal degrees prefixed with E or W 


</coord> 




<ang\e>nnn.nn</ang\e> 


Angle in degrees of rotation of the ellipse measured 
clockwise from north 


<semiMajor>nnnnn</semiMajor> 


Length of semiMajor axis in metres 


<semiMinor>nnnnn</semiMinor> 


Length of semiMinor axis in metres 


<angularUnit>aaaaaa</angularUnit> 


Unit for <angle> (Required LIF parameter but default unit 
is degrees!) 


<distanceUnit>nnnnn</distanceUnit> 


Optional - default unit is meter 


</ EllipticalArea > 




</shape> 




<alt>iir)nn</alt> 


Optional - Altitude of phone if available (in respect to 
coordinate ellipsoid NOT actual height)) 


<speed>nnnn</speed> 


Optional - speed in meters/sec if available 


<direction>nnnn</direction> 


Optional - Direction phone is moving if available 


<lev_conf>nnn</lev_conf> 


LIF optional but required by 112service - Indicates the 
probability as a percentage that the phone is located within 
the position area defined 


</pd> 




</eme_pos> 
</eme event> 




</emerep> 




</svc result> 
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8 



Emergency Location - Error responses (subset of LIF 
defined response) 



8.1 Generic error response 

Response for an error when requesting location (i.e. request not accepted). 



XML Code 


Notes 


<?xml version="1.0" ?> 




<!DOCTYPEsvc init SYSTEM 
"MLP SVC RESULT 300.DTD"> 




<svc result ver="3.0.0"> 


Service result for MLP Version 3.0.0 


<eme lia ver="3.0.0"> 


Emergency Location Immediate Answer for MLP Version 3.0.0 


<resu It resid='nnrf>aaaa. . .a</resu lt> 


Error code no and error code text - see LIF defined errors table 
below 


<add info>aaaa...a</add info> 


Optional - Additional information about the result 


</eme lia> 




</svc result> 





8.2 Position error response 



Response for an error when trying to obtain location (i.e. request accepted but location not available). 



XML Code 


Notes 


<?xml version="1.0" ?> 




<!DOCTYPE SVC init SYSTEM "MLP SVC RESULT 300.DTD"> 




<svc result ver="3.0.0"> 


Service result for MLP Version 3.0.0 


<eme_lia ver="3.0.0"> 


Emergency Location Immediate Answer for MLP 
Version 3.0.0 


<eme pos> 


Position answer 


<msid type="MSISDN">cccpppppppppp</msid> 


Position is for this MSISDN (formatted as Country 
Code + Phone Number) (GSM/3GPP should 
conform to TS 1 23 003) 


<poserr> 




<result resid='nnn'>aaaa...a</result> 


Error code no and error code text - see LIF 
defined errors table below 


<add info>aaaa...a</add info 


Optional - Additional information about the result 


<time u\.c_ofW'±hhmm">yyyymmddhhmmss</t\me> 


Local Date and Time of phone when position 
attempt was made 


</poserr> 




</eme pos> 




</eme lia> 




</svc result> 







Result codes (LIF defined) 



This table defines the result codes that indicate the result of the request or individual positioning 
The error codes are divided in ranges: 






- 


99 


Location server specific errors 


100 


- 


199 


Request specific errors 


200 


- 


299 


Network specific errors 


300 


- 


499 


Reserved for future use 


500 


- 


599 


Vendor specific errors 
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NOTE: For privacy reasons it might be needed to not report certain specific errors. In this case it is up to the 
implementation or configuration of the location server which errors will be reported. 

These are the errors defined in LIF MLP V3.0.0. They may well change in later versions. 



Resid 


Slogan 


Description 





OK 


No error occurred while processing the request 


1 


SYSTEM FAILURE 


The request can not be handled because of a general problem in the 
location server or the underlying network 


2 


UNSPECIFIED ERROR 


An unspecified error used in case none of the other errors applies. 
This can also be used in case privacy issues prevent certain errors 
from being presented 


3 


UNAUTHORIZED APPLICATION 


The requesting location-based application is not allowed to access 
the location server or a wrong password has been supplied 


4 


UNKNOWN SUBSCRIBER 


Unknown subscriber. The user is unknown, i.e. no such subscription 
exists 


5 


ABSENT SUBSCRIBER 


Absent subscriber. The user is currently not reachable 


6 


POSITION METHOD FAILURE 


Position method failure. The location service failed to obtain the 
user's position 








101 


CONGESTION IN LOCATION SERVER 


The request can not be handled due to congestion in the location 
server 


102 


CONGESTION IN MOBILE NETWORK 


The request can not be handled due to congestion in the mobile 
network 


103 


UNSUPPORTED VERSION 


The Location server does not support the indicated protocol version 


104 


TOO MANY POSITION ITEMS 


Too many position items have been specified in the request 


105 


FORMAT ERROR 


A protocol element in the request has invalid format. The invalid 
element is indicated in ADD INFO 


106 


SYNTAX ERROR 


The position request has invalid syntax. Details may be indicated in 
ADD INFO 


107 


PROTOCOL ELEMENT NOT SUPPORTED 


A protocol element specified in the position request is not supported 
by the Location Server. The element is indicated in ADD INFO 


108 


SERVICE NOT SUPPORTED 


The requested service is not supported in the Location Server. The 
service is indicated in ADD INFO 


109 


PROTOCOL ELEMENT ATTRIBUTE NOT 
SUPPORTED 


A protocol element attribute is not supported In the Location Server. 
The attribute is indicated in ADD INFO 


110 


INVALID PROTOCOL ELEMENT VALUE 


A protocol element in the request has an invalid value. The element 
is indicated in ADD INFO 


111 


INVALID PROTOCOL ELEMENT 
ATTRIBUTE VALUE 


A protocol element attribute in the request has a wrong value. The 
element is indicated in ADD INFO 


112 


PROTOCOL ELEMENT VALUE NOT 
SUPPORTED 


A specific value of a protocol element is not supported in the Location 
Server. The element and value are indicated in ADD INFO 


113 


PROTOCOL ELEMENT ATTRIBUTE VALUE 
NOT SUPPORTED 


A specific value of a protocol element attribute is not supported in the 
Location Server. The attribute and value are indicated in ADD INFO 



Resid 


Slogan 


Description 








201 


OOP NOT ATTAINABLE 


The requested OoP cannot be provided. 


202 


POSITIONING NOT ALLOWED 


The subscriber does not allow the application to position him/her for 
whatever reason (privacy settings in location server, LOS privacy 
class). 








204 


DISALLOWED BY LOCAL 
REGULATIONS 


The location request is disallowed by local regulatory requirements. 


207 


MISCONFIGURATION OF LOCATION 

SERVER 


The location server is not completely configured to be able to 
calculate a position. 








300 

499 




Reserved for future use 








500 
599 




Vendor specific errors 
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1 Proposed additional functionality - Position fix type 



10.1 Background 



From the proposed implementation of this functionality in July 2003 or soon after it is likely that some operators will be 
offering multiple position fix technologies. For example Cell-ID based plus EOTD and/or A-GPS. 

The Emergency Operator has two functional requirements: 

1) A very quick response to location request (accuracy not as important as response speed) 

This enables the Emergency Operator to route the call to the correct Emergency Authority based on 
approximate geographic location, to question the caller more appropriately to establish the exact location using 
approximate location details and in most cases to despatch the nearest response vehicle. 

2) A most accurate response to a location request (accuracy more important then response speed) 

This may be required if the Emergency Authority cannot determine exactly where the caller is, for example 
after talking to the caller. 

10.2 Issue 

In a network providing more than one location technology, (e.g. both Cell-ID and A-GPS) these two requirements 
require two different requests. 

By utilizing the standard LIE optional QOP (Quality Of Position) parameters (e.g. horizontal accuracy and how long 
before a response is required) it may be possible for the Emergency Operator to request a Cell-ID fix and then a A-GPS 
fix but this would require the Emergency Operator to know the capabilities and necessary parameters for each network 
and each caller's handset and configure these in their software client. 

This appears to be an unnecessary burden on the parties involved to implement the parameters and maintain the 
parameters over time. 



10.3 Proposed solution 



The Mobile Operator knows both the capability of his network (e.g. Cell-ID + A-GPS) and the capability of the handset 
being utilized by the El 12 caller (e.g. has or does not have A-GPS or EOTD capability). 

The proposed solution is therefore that the Emergency Operator tells the Mobile Operator what type of fix is required 
(as in clause 10.1) and the Mobile Operator maps that request to the Operator's appropriate location fix technology with 
whatever parameters are required for that Operators implementation). 

This functionality could be included in the protocol described in the present document by utilizing the LIF optional 
<loc_type> element and the addition of two new values to the element as follows. 



LIF 3.0 possible values 


Response Required 


<loc_type type='CURRENT' /> 


Refer to TS 122 071 and TS 129 002 for 
definition 


<loc_type type='LAST' /> 


Refer to TS 1 22 071 and TS 1 29 002 for 
definition 


<loc_type type='CURRENT_OR_LAST' /> 


Refer to TS 122 071 and TS 129 002 for 
definition 


<loc_type type='INITIAL' /> 


Refer to TS 1 22 071 and TS 1 29 002 for 
definition 


Proposed New Additions 




<loc type type='CURRENT FAST'/> 


Fastest possible current location fix is required 


<loc type type='CURRENT ACCURATE' /> 


Most accurate current location fix is required 
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Note that in situations where: 

• only Cell-ID implemented; 

• or where EOTD or A-GPS is implemented but a fix is not available at the time; 

• the response to both requests may in fact be the same (e.g. Cell-ID). 

The response elements <EllipticalArea> and <lev_conf> will enable the Emergency Operator to determine the accuracy 
of the response. 

The Emergency Location Immediate Request (see clause 6.1) would then become (addition in italics). 



XML Code 


Notes 


<?xml version="1.0" ?> 




<!DOCTYPE SVC init SYSTEM "MLP SVC INIT 300.DTD"> 




<svc init ver="3.0.0"> 


Service initiation for IVILP Version 3.0.0 


<hdrver="3.0.0"> 


Header for MLP Version 3.0.0 


<client> 


Who is requesting this location fix 


<\6>aaaa....a</\6> 


Emergency operator registered user name for login 


<pwd>aaaa. . . a</pwd» 


Optional - Emergency operator password for login 


</client> 




</hdr> 




<eme_lir ver="3.0.0"> 


Emergency Location Immediate Request for MLP 
Version 3.0.0 


<msids> 


Identifier of device to be located 


<msid type="MSISDN">ccpppppppppp</msid> 


Identifier is a MSISDN formatted as Country Code + 
Phone Number (GSM/3GPP should conform to TS 
123 003) 


</msids> 




<loc_type type='tttt....t'/> 


Where "tttt....t" is eitlier "CURRENT FAST" or 
"CURRENT ACCURATE" 


</eme lir 




</svc init> 





10.4 Proposed action 



Propose the addition of the CURRENT_FAST and CURRENT_ACCURATE values to the <loc_type> element within 
MLP at the LIE meeting in September 2002. 



1 1 Proposed additional functionality - HTTP 1.1 
pipelining 



11.1 Background 



Emergency services require the quickest possible response to requests for the location of a caller. 

It is therefore proposed that the Emergency Operator will utilize pipelining as defined the HTTP LI to enable them to 
submit requests for location sequentially without waiting for a response. 

Under HTTP 1 . 1 responses should be returned in the same order as the requests were received. 

11.2 Issue 

For emergency operators the following use case is unacceptable. 

Assume that an operator has implemented both Cell-ID and A-GPS based positioning technologies. 
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If the emergency operator submits a location request for one MSISDN which causes the network to initiate an A-GPS 
fix and then immediately follows it with a request for another MSISDN which causes the network to initiate a Cell-ID 
based fix, then following the HTTP 1 . 1 standard the operator cannot return the cell-ID based location result until it has 
returned the A_GPS based location result. 

As the A-GPS based fix may take 30 s to 60 s and the Cell-ID based fix may take only 1 s to 2 s the potential delay of 
28 s 59 s in returning the cell-id based result to the emergency operator in unacceptable. 

1 1 .3 Proposed solution 

11.3.1 HTTP 1.1 non conformance 

Return results to emergency operator from network as each result is available. This implies that the results returned may 
not be in the same order that the requests were received as required by HTTP 1.1. 

1 1 .3.2 Utilize a transaction ID 

In order that the emergency operator can match potentially out of order responses with the appropriate request a 
transaction ID needs to be added by the emergency operator to each request and the same transaction ID returned by the 
operator with each valid response or error response. 

Note that because of dropped calls it is possible that the emergency operator may submit a request for an MSISDN 
before a previous request for the same MSISDN has been responded to. Therefore the MSIDN is not sufficient to match 
requests and responses. 

1 1 .4 Proposed action 

Add a transaction ID element to MLP. 



1 2 European petroleum survey group 



12.1 Background 



The European Petroleum Survey Group (EPSG) was formed in 1986. It comprises specialist surveyors, geodesists and 
cartographers from European Oil Companies. Meetings are held twice yearly to discuss survey and positioning topics 
within those areas of oil industry business where cooperation is generally agreed to be mutually beneficial. 

A geodesy working group maintains a relational database of EPSG geodetic parameters. 

The EPSG aims to help member companies, and where relevant others, by the dissemination of information which by 
generally improving oil industry survey practices and procedures, will contribute to increased efficiency, enhanced 
quality, improved safety of operations and the protection of the environment. 

Through its membership of specialist professionals, the EPSG is qualified to offer collective expert advice to member 
companies within the fields of geodesy, surveying, positioning and cartography where they relate to oil exploration, 
development and production operations. 



12.2 EPSG geodetic parameters 



EPSG, through its geodesy working group, maintains and publishes a data set of parameters for coordinate system and 
coordinate transformation description. The data is supported through formulae given in guidance note number 7. The 
EPSG geodetic parameters have been included as reference data in the GeoTIFF data exchange specifications, in Iris21 
(Petroconsultant's data model) and in Epicentre (the POSC data model). The parameters are maintained in an MS 
Access relational database and may be consulted on this site. 
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12.3 EPSG guidance notes 



EPSG produces an occasional series of Guidance Notes for its member use. Some are made publicly available from this 

site. 

Associations with other organizations PSG has: 

• category A liaison membership of the International Standards Organization (ISO) Technical Committee 211, 
Geographic Information/Geomatics; 

• a strong, but informal, relationship with the UKOOA Survey and Positioning Committee; 

• a strong, but informal, relationship with the Petrotechnical Open Software Corporation (POSC) to which it 
provides geodetic advice and support through the EPSG geoesy working group; 

• EPSG geodesy working group members maintain a liaison with the Open GIS Consortium over spatial 
referencing and coordinate transformation; 

• EPSG maintains links with the Americas Petroleum Survey Group (APSG). 

1 2.4 EPSG Geodesy Parameters V 6.3 

In February 2002, the European Petroleum Survey Group (EPSG) completed and released the ISO-compliant 
Version 6.1 data model and data set. The move to the new model was made to encourage standardisation both across the 
Exploration and Production segment of the oil industry and in the geodetic community at large. Since that release, much 
new data has come available. 

This new Version 6.3 [ 

] is the current EPSG release, distributed in an MS Access 97 database. It incorporates data received and verified since 
the release of Version 6.1. There are no changes in the data model from Version 6.1. 

NOTE: Version 6.3 [relational] database is only available in MS Access v97 but can be converted to Access 
2000. 

Note that this zipped file is comprised of the v6.3 database (MS Access 97) and associated documentation 
(in both Adobe Acrobat PDF and MS Word 97-2000& 6/95-rtf formats). The zipped file is approximately 
2 Mb in size. 

There are no significant changes in content from the v6.2.2, v6.2.1 and v6.2 versions of the database that are superseded 
by this v6.3 database. Some changes were made primarily to form controls to assist user conversion to Access 2000. 
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Annex A (informative): 
Bibliography 

EPSG guidance notes documentation (See Guidance Notes). 



ETSI TS 123 003: "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications 
System (UMTS); Numbering, Addressing and Identification (3GPP TS 23.003)". 

ETSI TS 122 071; "Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile 
Telecommunications System (UMTS); Location Services (LCS); Service description, Stage 1 (3GPP TS 22.071)". 

ETSI TS 129 002: "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications 
System (UMTS); Mobile AppUcation Part (MAP) specification (3GPP TS 29.002)". 
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